uiiiiiriiiiiiiiniiiiii mi 

US006385769B1 

(12) United States Patent (io) Patent No.: US 6,385,769 Bl 

Lewallen (45) Date of Patent: *May 7, 2002 



(54) TEXT BASED OBJECT ORIENTED 
PROGRAM CODE WITH A VISUAL 
PROGRAM BUILDER AND PARSER 
SUPPORT FOR PREDETERMINED AND NOT 
PREDETERMINED FORMATS 

(75) Inventor: Stephen Lewallen, Cupertino, CA (US) 

(73) Assignee: International Business Machines 
Corporation, Armonk, NY (US) 

(*) Notice: This patent issued on a continued pros- 
ecution application filed under 37 CFR 
1.53(d), and is subject to the twenty year 
patent term provisions of 35 U.S.C. 
154(a)(2). 

Subject to any disclaimer, the terra of this 
patent is extended or adjusted under 35 
U.S.C. 154(b) by 0 days. 

(21) Appl. No.: 09/243,251 

(22) Filed: Feb. 3, 1999 

(51) Int. CI. 7 G06F 9/44 

(52) U.S. CI 717/125; 717/143; 717/116 

(58) Field of Search 717/1, 6, 125, 

717/143, 116 

(56) References Cited 

U.S. PATENT DOCUMENTS 

5,446,902 A * 8/1995 Islam 395/703 

5,546,519 A 8/1996 Berry 

5,642,511 A 6/1997 Chow et al. 

6,286,138 Bl * 9/2001 Purcell 717/U 

OTHER PUBLICATIONS 

"The Theory of Parsing, Translation and Compiling vol. 
l:Parsing", A.V. Aho et al. Table Of Contents, 1972.* 
"Object-Oriented Compiler Construction", Jim Holmes, 
Nov. 24, 1994, pp. 1-15, 19-24, 75-124, 185-246.* 



"Understanding ActiveX and OLE A Guide for Developers 
& Managers", David Chappell, Microsoft Press, Chapters 
1-3,5,7,9,10 and Index, Sep. 24, 1996.* 

The Java and HoJava Object Models, by Michael Weiss, 
Andy Johnson, and Joe Kiniry, Version 2.1, Feb. 9, 1996, pp. 
1-10. 

Overview of Java and Hotjava, by Michael Weiss, Andy 
Johnson, and Joe Kiniry, Version 2.1, Feb. 9, 1996, pp. 1-6. 

A First Look into VisualAgc for Java, by Bob Brodd and 
Mark Lorenz, pp. 1-6. 

Providing Easier Access to Remote Objects in Distributed 
Systems, by Jonathan Aldrich, James Dooley Scott Mandel- 
sohn and Adam Rifkin, Nov. 21, 1997, pp. 1-35. 

* cited by examiner 

Primary Examiner — Gregory Morse 

Assistant Examiner— -Todd Ingberg 

(74) Attorney, Agent, or Firm— Kudirka & Jobse, LLP 

(57) ABSTRACT 

Text-based object-oriented class code, located in either local 
or remote machines is converted into proxy components 
which can be used in existing visual builders. Proxy com- 
ponents are created from each method, including 
constructors, in the class code and encapsulate the param- 
eters of the methods. For example, parameters associated 
with a method are represented by properties of the proxy 
component created from that method. These properties are 
visually editable and can be bound visually to other com- 
ponent properties using, for example, pull down menus in a 
visual builder. Exceptions which occur during operation of 
the method are treated as events and can be visually passed 
to other components. An add-on allows the components to 
appear directly in the visual builder palette. The components 
can interact with the text-based class code by means of a 
universal transport API. 
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TEXT BASED OBJECT ORIENTED 
PROGRAM CODE WITH A VISUAL 
PROGRAM BUILDER AND PARSER 
SUPPORT FOR PREDETERMINED AND NOT 
PREDETERMINED FORMATS 

FIELD OF THE INVENTION 

The present invention relates, in general, to software 
programming systems and methods, and more specifically, 
to visual programming techniques for use with object- 
oriented software languages. 

BACKGROUND OF THE INVENTION 

Software is increasingly becoming a major portion of cost 
associated with computer systems because it is very "labor- 
intensive." Some of this cost is due to the effort involved in 
writing and debugging programs, other costs involve main- 
taining programs after they have been written. Accordingly, 
considerable effort has been expended in order to reduce the 
time and costs involved with writing, debugging and main- 
taining moderate and large software programs. Much of this 
effort has been related to developing programming lan- 
guages and programming techniques which will allow pro- 
grammers to build on or "reuse" programs and code seg- 
ments that have been written by others. 

Until very recently, software programming was heavily 
dominated by an approach referred to as "structured pro- 
gramming." Common software programming languages 
used in this approach were, and remain, BASIC, 
FORTRAN, and PASCAL. These are considered "higher 
order" languages that are written in human readable code 
and ultimately translated into machine or computer readable 
code by a compiler. Typically, structured programs have 
consisted of a combination of defined variables of specific 
data types, e.g. integer, real, and character, and a compli- 
mentary set of functions or routines which operate on these 
variables. Often, a program would include sub-routines 
which are smaller routines within a program or larger routine 
that carry out certain operations, e.g. printing data in a given 
output format. The emphasis to this approach was inputs — 
functions — outputs and they were often represented as flow- 
charts by the designers, which logically represented how the 
program functioned and branched into different functional 
paths. As an increasing number of programs became large 
(tens of thousands of lines of code and above) structured 
programs became increasingly complex and difficult to 
write, troublesboot and maintain. 

Flowcharts became unwieldy and the tracking of errors 
through permutations of variables, lengthy code, and a wide 
variety of program branches was time and cost intensive and 
often produced less than adequate results. Consequently, a 
new approach to software programming called Object- 
Oriented Design (OOD) or Object-Oriented Programming 
(OOP) emerged and has gained increasing popularity among 
software developers. OOP promised greater reuse and main- 
tainability than its structured programming predecessor 
because of an emphasis on well-defined and self contained 
objects, rather than the structured programming emphasis on 
a proliferation of relatively loosely-related data manipulat- 
ing functions and subroutines. 

Object Oriented Programming techniques involve the 
definition, creation, use and destruction of "objects." These 
objects are software entities comprising data elements, or 
attributes, and methods, or functions, which manipulate the 
data elements. The attributes and related methods are treated 
by the software as an entity and can be created, used and 
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destroyed as if they were a single item. Together, the 
attributes and methods enable objects to model virtually any 
real-world entity in terms of the entity's characteristics, 
represented by the data elements, and the entity's behavior, 

5 represented by data manipulation functions or methods. In 
this way, objects can model concrete things like people and 
computers, and they can also model abstract concepts like 
numbers or geometrical designs. 
Objects are defined by creating "classes" which are not 

1Q objects themselves, but which act as templates that instruct 
the computer how to construct the actual object. Aclass may, 
for example, specify the number and type of data variables 
and the steps involved in the methods which manipulate the 
object's data. When an object-oriented program is compiled, 
the class code is compiled into the program, but no objects 

15 exist. Therefore, none of the variables or data structures in 
the compiled program exist or have any memory allotted to 
them. An object is actually created by the program at 
runtime by means of a special function called a "construc- 
tor" which uses the corresponding class definition and 

20 additional information, such as arguments provided during 
object creation, to construct the object. Likewise, objects 
can be destroyed by a special function called a "destructor" 
or can be destroyed by special programs called "garbage 
collectors" when no longer needed. Objects may be used by 

25 using their data and invoking their methods. When an object 
is created at runtime, memory is allotted and data structures 
are created. 

The principle benefits of object-oriented programming 
techniques arise out of three basic principles; encapsulation, 

30 polymorphism and inheritance. Specifically, objects can be 
designed to hide, or encapsulate, all, or a portion of, the 
internal data structure and the internal methods. More- 
particularly, during program design, a program developer 
can define objects in which all or some of the attributes and 

35 all or some of the related methods are considered "private" 
or for use only by the object itself. Other data or methods can 
be declared "public" or available for use by other programs. 
Access to the private variables by other programs can be 
controlled by defining public methods for an object which 

40 access the object's private data. The public methods form a 
controlled and consistent interface between the private data 
and the "outside" world. Any attempt to write program code 
which directly accesses the private variables causes the 
compiler to generate an error during program compilation 

45 which error stops the compilation process and prevents the 
program from being run. 

Polymorphism is a concept which allows objects and 
functions which have the same overall format, but which 
work with different data, to function differently in order to 

50 produce consistent results. For example, an addition func- 
tion may be defined as variable A plus variable B (A+B) and 
this same format can be used whether the A and B are 
numbers, characters or dollars and cents. However, the 
actual program code which performs the addition may differ 

55 widely depending on the type of variables that comprise A 
and B. Polymorphism allows three separate function defi- 
nitions to be written, one for each type of variable (numbers, 
characters and dollars). After the functions have been 
defined, a program can later refer to the addition function by 

60 its common format (A+B) and, at runtime, the program will 
determine which of the three functions is actually called by 
examining the variable types. Polymorphism allows similar 
functions which produce analogous results to be "grouped" 
in the program source code to produce a more logical and 

65 clear program flow. 

The third principle which underlies object-oriented pro- 
gramming is inheritance, which allows program developers 
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to easily reuse pre-existing programs and to avoid creating ODBC, JDBC, and flat-file, and directory services, e.g. 

software from scratch. The principle of inheritance allows a LDAP and URL. This variation in systems causes incom- 

sofrware developer to declare classes, and the objects which patibilities and inefficiencies in sharing code. Often times, 

are. later created from them, as related. Specifically, classes programmers will have to modify code received from others 

may be designated as subclasses of other base classes. A 5 m order to make it re-useable. This additional work tends to 

subclass "inherits" and has access to all of the public decrease code reuse and, even if reuse is attempted, stretch 

functions of its base classes just as if these .functions out lhe development for new applications, 

appeared in the subclass. Amatively, a subclasses* over- ^ a Qumbcr of 

ndesomeoraUoffe architectures were developed. These include the 

01 f f Tul^ , n S m T V Y 3 T W 10 Common Object Request Broker Architecture (CORBA) 

method wxthtr* ^ and Rcm J otc ^ ^ ^ ^ ^ 

not alter the method in the base class^ut merely modifies C0RfiA architcctufC „ lRt J iCC £J niliotl j^. 

the use of the method ,n the subclass The creation of a new which ^ differcnt ^ 

subclass which has some of the functionality, with selective £ standardized interfaces so that the objects 

modification, of another class aUows software develope rs to ^J J' bg ^ tQ communicate> CORBA and RMI also 
easily customs existing code to meet their "amcu^edggg. , . mcchanisms for transporting communications 

^^^SS^&SSSSnSW^^ includeJgiUJjBW between remotely-located objects which have interfaces that 
^BCTHF^ an conform to their specifications. CORBA and RMI have 
expx^!S3impliea object model. Generally speaking, an aUowed interoperability among objects written in various 
object model is a unifying set of rules that describe object 20 0Qp la and for ^ on various platforms . 
structure, object life cycle, and inter-object communication. TJJ --- • ^ • . , 
Object structure relates to the physical layout of objects in | Q addltlon m order t0 morc efficient languages to 
memory, while object life cycle refers to how applications « dut ? Programming time, programming techniques have 
create and destroy objects. Inter-object communication also be f. n un P roved - Imt f * Program were writ en by 
refers to protocols by which objects communicate with one 25 ^"8 luies ° f P"&™ statements, n the case of OOP 
another. Object models are useful in contexts where all F«*»ms, Ume was spent entering information with corn- 
objects in a given system need to conform to a given Plated syntax which was relatively standard from object to 
. . _ , », „ f • . A object. For example, for each constructor or method, a 
protocol governing these parameters. Most object-oriented J r ' , , . 
and object-based languages, including the Java program- Programmer normally wrote lines of code to marshal the 
ming language, do not specify true object models, but 30 data for each I^T.T ■ ^ ? °l ^ 
merely specify syntax and semantics of a basic object Programmer Uien had to write a code line to call the method, 
implementation without specifying the actual rules that n ^ °f me Programmer had to write code 
untfy object systems. Some object-oriented languages also J™* "P^ aad stor ! *J e , resul < of th / me ' hod Ca "- 
incorporate the notion of "components" which are self- Fma1 ^ the programmer had to wnte code to deal with 
contained objects that perform a specified function or pro- 35 f^P^otis that occurred dunng the method call. This was 
cedure. Components have a pre-defined interface that con- tedl ,°. us md led *° a P ? ? ty P° Er * phlCal and 
forms to the object model of the underlying language and speUm S errors wmch increased the bugging time, 
generally conform to a "component model" associated with However, recently, "visual builders" are increasingly 
the language. being used to expedite programming. A visual builder allows 

Initially, the promise of reusability and economy of OOP 40 Programs to be written with the help of a Graphical User 
was not realized. Standards were not in place to insure Inter face (GUI). Objects can be represented by icons which 
interoperability of objects or cross-platform interoperability. encapsulate the "standard" portions of the code and allow 
This problem became even more evident when the Internet Program developers to create program code for objects by 
and the World Wide Web (Web) emerged as widely-used specifying the object properties and writing code for the 
resources and ensured that a wide variety of platform 45 object methods. The visual builder then generates the actual 
configurations would attempt to access and use commonly- class code for d» object, including the code for marshaling 
available information on the Internet. As a result, applica- data and handling results and exceptions. Many visual 
lions designed to operate on the Web used languages builders contain predefined components which can be cus- 
designed specifically for the Web, such as hyper-text mark- tomized or uscd t0 derive oth er components. These pre- 
up language (HTML) as a way to provide a static, but 50 defined exponents are generally represented as icons on a 
commonly useable, form of coded information while object- "palette", to which new components can be added. A pro- 
oriented programming was applied in other applications. But grammer using the visual builder manipulates these com- 
the problem of cross-platform interoperability persisted and P onenls 00 lhe ^reen, or " m the ac,ive window" or 
grew as it became more desirous to add dynamic capability "workspace", to create new components, 
to the Web and as many organizations were using multiple 55 In some visual builders, the objects or components can 
platforms and grappling with interoperability internally. also be linked by the programmer using the visual builder 
Also, the proliferation of objects conforming to different interface to create a unique program. As a result, it is not 
object models prevented significant reuse, as originally necessary, to some degree, for a visual programmer to spend 
envisioned. as much time entering code and debugging minor mistakes 

Recently, along with the increased distribution of code 60 as a typical software developer who must enter the code text 

among dissimilar systems for use, there has also been an directly. 

increased desire for programmers to share code over a Examples of visual builders are disclosed in U.S. Pat. No. 

distributed system. A distributed system is one in which 5,546,519 to Berry, which illustrates describes a system and 

there are typically multiple computer systems accessing or method for the visual programming of iterator link objects 

sharing information among one another. Client-server 65 using a standard visual builder, whereby the user need not 

systems, for example, are distributed computer systems. know the programming language itself. Properties of objects 

Ttese various systems use a variety of persistent stores, e.g. are also editable, usually via pull-down menus, and new 
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objects can be added to the visual builder palette, primarily remote transport implementation allows a user to access and 

as a function of the visual builder itself. use OOP classes resident on other computers, even if the 

In U.S. Pat. No. 5,642,511 to Chow et. al., a system and classes do not conform to either the Remote Method Invo- 

method are described for implementing an improved visual ™ l ™ °TT n 

builder which allows a program developer to manipulate a 5 to*un> (CORBA) specifications .without manually wrapping 

, . u- w i . J^v t .1 the classes. Invocations of methods and constructors, and 

hierarchical tree used to represent an OOP program. In the tions ted b the durin the method mvocaUoriS 

Chow patent a "proxy tree comprised of proxy objects is are each en * apsulated mt0 classes m a way which 

built by using a visual builder to copy and edit user selected permits h|e binding an(J aUows tbe invocation in f ormat ion 

objects, thereby creating a new program. to ^ serialized. 

Visual builders are attractive because they help to reduce 10 \ R accordance with another embodiment, a component- 
programming time. However, each object or component oriented compiler can parse any text-based OOP source code 
used in the visual builder must be built by customizing an and create components for each of its public constructors 
existing visual builder class or by creating a new component and methods. The compiler retrieves all relevant entities, 
"from scratch." It would be desirable to be able to use such as constructors, methods, fields, comments and param- 
existing objects and components, represented by textual 15 eter names. The parameters, fields, and properties of a 
program code, with such builders. To date, there is no constructor become the bound properties of the resultant 
automated way to create components which can be directly constructor component. The parameters of a method become 
used in the builders from unparsed object-oriented class "ie bound properties of a method component. Finally, the 
code statements. Therefore, in order to use objects created method component includes a special bound property called 
from such classes, a program developer must recreate the 20 " result " which contains the result of a method event. The 
class or component with the builder by appropriately defin- compuer compiles the code it generates creates a manifest 

ing the properties and coding the methods file ; aU files 10 an a / cbive ^ . , 
„ , . . In accordance with yet another embodiment, a visual 
Additionally, when components are created using a visual environmeQt addK)n (VE A) program operates with a stan- 
builder, it is desirable to test them within the V!sual builder 25 dard visual buUder to ix applications to be 
application without creating objects from the components built me need to include any extra programming 
and incorporating them into applications. However, current steps to preserve exceptions or properties. The VEA pro- 
visual builders do not allow the components to be tested in g ram allows an OOP component, including those generated 
this efficient manner. Instead, they require an object to by the aforementioned compiler, to be placed on the existing 
actually be constructed from the component before the 3Q palette of the visual builder so that the component can be 
object can be tested. If the object works, it is assumed that manipulated by the visual builder to generate a component- 
tbe component coding is correct. Once a component is tested based application. 

and shown to operate correctly, then it can be safely incor- BRIEF DESCRIPTION OF THE DRAWINGS 
porated in to a visual builder palette for use by other ™ . . , . , , . 
developers above and further advantages of the invention may be 
„ ' , , , , 35 better understood by referring to the following description in 
Consequently, a need exists for a method and apparatus coojunction ^ thc accompanying figures, described 
for creating object oriented component, from existing object below- 
oriented text-based code. A need also exists for creating FIG. 1 is a block diagram of a computer system suitable 
these components m accordance with defined object for use with , he present mvention , 
standards, e.g. CORBA and IDL. Furthermore, a need exists 40 pjQ 2 is a schematic block diagram of a bean creator 
to create these components in such a manner that the consu^cted in accordance with the principles of the present 
newly -created components can be used with existing visual invention. 

builders. FIG. 3 is a more detailed block diagram of a bean 

SUMMARY OF THE INVENTION ^i? 6 !". , . L1 , , , JL . 

45 FIG. 4 is a schematic block diagram of classes used by the 

An inventive method and system convert text -based be an compiler of FIG. 3. 

object-oriented class code, located in either local or remote FIG. 5 is a flowchart depicting the steps in an illustrative 

machines into proxy components which can be used in routine for generating a constructor bean, 

existing visual builders. Proxy components are created from fig. 6 is a flowchart depicting the steps in an illustrative 

each method, including constructors, in the class code and 50 routine for generating a method bean, 

encapsulate the parameters of the methods. For example, piG. 7 is a more detailed schematic block diagram of a 

parameters associated with a method are represented by bean visual environment add-on illustrating the relationship 

properties of the proxy component created from that with a visual builder. 

method. These properties are visually editable and can be FIG. 8 is a flowchart depicting the steps in an illustrative 

bound visually to other component properties using, for 55 routine for generating a bean-based application using the 

example, pull down menus in a visual builder. Exceptions inventive apparatus and method. 

which occur during operation of the method are treated as F IG. 9 is a schematic block diagram of interface and 

events and can be visually passed to other components. implementation classes composing a universal transport API 

In accordance with one embodiment, a universal transport of the illustrative embodiment, 

application programming interface (API) provides a mecha- 60 piG. 10 is a schematic block diagram illustrating the 

nism for manipulating objects in a "component-oriented" control of class implementations by a constructor and 

manner on either local or remote platforms. Essentially, the method bean using the universal transport API. 
universal transport API is an object request broker which is 

controlled by the proxy components and includes two trans- DETAILED DESCRIPTION OF THE 

port implementations: one for local transport and one for 65 PREFERRED EMBODIMENT 

remote transport. The local transport implementation allows FIG. 1 illustrates the system architecture for a computer 

access to local OOP code resident on a user's computer. Tbe system 100 such as an IBM PS/2®, on which the invention 
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may be implemented. The exemplary computer system of 
FIG. 1 is for descriptive purposes only. Although the 
description may refer to terms commonly used in describing 
particular computer systems, such as in IBM PS2 computer, 
the description and concepts equally apply to other systems, 
including systems having-architectures dissimilar to FIG. 1. 

Computer system 100 includes a central processing unit 
(CPU) 105, which may be implemented with a conventional 
microprocessor, a random access memory (RAM) 110 for 
temporary storage of information, and a read only memory 
(ROM) 115 for permanent storage of information. A 
memory controller 120 is provided for controlling RMA 
110. 

A bus 130 interconnects the components of computer 
system 100. A bus controller 125 is provided for controlling 
bus 130. An interrupt controller 135 is used for receiving and 
processing various interrupt signals from the system com- 
ponents. 

Mass storage may be provided by diskette 142, CD ROM 
147, or hard drive 152. Data and software may be exchanged 
with computer system 100 via removable media such as 
diskette 142 and CD ROM 147. Diskette 142 is insertable 
into diskette drive 141 which is, in rum, connected to bus 30 
by a controller 140. Similarly, CD ROM 147 is insertable 
into CD ROM drive 146 which is, in turn, connected to bus 
130 by controller 145. Hard disk 152 is part of a fixed disk 
drive 151 which is connected to bus 130 by controller 150. 

User input to computer system 100 may be provided by a 
number of devices. For example, a keyboard 156 and mouse 
157 are connected to bus 130 by controller 155. An audio 
transducer 196, which may act as both a microphone and a 
speaker, is connected to bus 130 by audio controller 197, as 
illustrated. It will be obvious to those reasonably skilled in 
the art that other input devices, such as a pen and/or tabloid 
may be connected to bus 130 and an appropriate controller 
and software, as required. DMA controller 160 is provided 
for performing direct memory access to RAM 110. A visual 
display is generated by video controller 165 which controls 
video display 170. Computer system 100 also includes a w 
communications adaptor 190 which allows the system to be 
interconnected to a local area network (LAN) or a wide area 
network (WAN), schematically illustrated by bus 191 and 
network 195. 

Operation of computer system 100 is generally controlled 45 
and coordinated by operating system software, such as the 
OS/2® operating system, available from International Busi- 
ness Machines Corporation, Austin, Tex. The operating 
system controls allocation of system resources and performs 
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Java is referred to as a "bean,** and includes a defined 
interface. Java beans are used within applets and applica- 
tions and a programmer need not know the internal structure 
of the Java bean to use it, he need only know the interface. 
In addition, once the interface of a bean is known, a 
programmer can create a new customized component from 
the base Java bean component. The Java bean contains 
properties and methods, which can be changed when another 
bean is derived created from the bean, which is how cus- 
tomization of the new component is achieved. 

Because Java programs are intended to be transmitted 
over the Internet, the final program is packaged into what is 
referred to as a Java Archive (JAR) file. The JAR file is 
actually a "zipped", or compressed, file which includes all 
related files for that application, applet, or component. Also 
included in the JAR file is a manifest file, which includes 
extra information concerning the zipped portion of the file. 
For example, the manifest file can indicate the contents of 
the JAR file and whether a particular zipped file is a bean or 
a resource file, its file version number, and so on. 

Since Java is well-suited to operation over networks, the 
following description of the illustrative embodiment is 
directed toward the Java programming language. However, 
it will be obvious to those skilled in the art that the invention 
could be implemented for other OOP languages as well, e.g. 
C++. 

FIG. 2 shows an illustrative embodiment of a component 
creator apparatus 200 constructed in accordance with the 
principles of the present invention which is used with 
computer 100, or its equivalent. In accordance with Java 
terminology, the component creator 200 will hereinafter be 
referred to as "bean creator" 200. The inventive apparatus 
enables a computer user or programmer to build "bean- 
based" applications 216 from existing text-based OOP code 
202, 204 using a standard visual builder 214. The primary 
components of the illustrative embodiment 200 are universal 
transport API 206, bean compiler 208, and bean visual 
environment add-on 212. The bean creator 200 may be used 
for building applications on distributed systems or indepen- 
dently on a single computer. 

OOP object and component interfaces 204 which define 
the objects and components which are to be used with the 
system are provided to a bean compiler 208. As previously 
mentioned, the bean compiler 208 converts each component 
into proxy components 210, where each method in the 
component is converted into a separate proxy component of 
the components 210. The proxy components 210 can be 
manipulated with the help of a conventional visual builder 
214 which has been provided with a bean visual environ- 
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tasks such as processing scheduling, memory management, 50 ment add-on that allows the proxy components to be rec- 
ognized by the visual builder. 

fsing the visual builder an application 216 can be created 
Fit]) the proxy components. This application is essentially a 
collection of customized components. Each customized 
component is ao interconnected collection of proxy compo- 
nents. 

Each customized component in the application 216 can be 
tested within the visual builder by means of the universal 
transport API 206 which allows the code which implements 
60 the underlying objects and components 202 to be exercised 
under control of the proxy components. If the customized 
component does not operate properly, it can be rebuilt within 
leaving the visual builder environment. The different por- 
tions of the illustrative embodiment are discussed in more 
65 detail below. 

Referring to FIG. 3, the bean compiler 208 of the illus- 
trative embodiment is shown in more detail. Bean compiler 
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__ filed on a particular platform by means of a 

^faaflSlSi%achine , ' (VM) which allows a Java program to be 
run on any platform, regardless of whether the Java program 
was developed on, or for, the particular platform which 
attempts to run the Java program. Java bytecodes which 
arrive at the executing machine are interpreted and executed 
by the embedded VM. 

A complete Java program is known as an application, 
while a segment of Java code, which does not amount to a 
full application, but is reusable, is referred to as an "applet". 
Java also includes a component model. A component within 
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300 accepts text-based Java class code from any source file 
302, including Java class files and Java bean files. Bean 
compiler 302 parses the code and extracts the relevant 
methods and parameters. Illustratively, the OOP class code 
is the interface code for a Java class which includes two 
constructors (Constructor 1 and constructor 2), four methods 
(Method 1, Method 2, Method 3 and. Method 4). Identifiers 
from two exceptions (Exception 1 and Exception 2) are also 
included. These latter identifiers can be text messages or 
other identification code. Code 302 may also be source code 
for a component such as a Java bean. 

Bean compiler 300 includes a parser/extractor 304 which, 
in turn, includes methods that parse and extract code from 
each Java class. Such a parser/extractor is conventional and 
may, for example, be similar to a parser used in a compiler 
which responds to source code by parsing and extracting 
keywords and other identifiers. From each class, the parser/ 
extractor 304 parses each constructor and each method and 
extracts any related fields, comments, and parameter names. 
Using the extracted constructor information, the compiler 
module 306 creates and compiles a constructor bean such as 
beans 318 and 320. The compiler 306 also creates a method 
bean from extracted information for each method in the 
class, for example method beans 310-316. 

As the beans are created they are inserted into a JAR file 
324 by JAR File loader 322, Once all of the beans have been 
created, another module, the manifest file creator 308, of 
bean compiler 306 produces a complete manifest file, with 
an ",mf suffix. Manifest files are customary in the Java 
programming language and well known, so will not be 
discussed in detail herein. 

The compiler module extracts more detailed information 
than previously extracted by various conventional process- 
ing. For example, assume the following method existed in 
the interface class 302: 

public Address getAddress 
String firstName, 
String lastName); 

Unlike the conventional extraction process of 
"reflection", which would only determine that the method 
takes as parameters two string objects, the bean compiler 
300 extracts the actual parameter names "firstName" and 
"lastName". Extracting these parameter names allows these 
parameters to be converted to properties of the method bean 
created from the original method "getAddress". Maintaining 45 
these parameters as properties allows more flexibility in the 
construction and customizing of new beans created from the 
getAddress method bean. 

As previously mentioned, component creator 200 func- 
tions to convert text based Java class code and other Java 
beans into beans which can be combined to form a "bean- 
based" application by a conventional visual builder. In 
particular, Java class or Java bean interface code 204 is 
provided to bean compiler 208. Code 204 is either local or, 
in the case of a distributed object system, is generally 
exported by the remote server. As previously mentioned, 
bean compiler 208 generates a constructor bean for each 
constructor in the code and a method bean for each method. 
These beans 210 are provided to a visual builder 214. In 
accordance with the principles of the invention, visual 
builder 214 includes a bean visual environment add-on 212, 
which allows the beans 210 to appear directly on the 
builder's object palette. The beans can therefore be manipu- 
lated in a conventional fashion using builder 214 to generate 
a bean-based application 216. 

The bean-based application 216 operates in conjunction 
with the universal transport API 206 to access the Java 
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objects instantiated from a selected class called the "target" 
class in the class and bean implementations 202. In 
particular, universal transport API 206 operates under con- 
trol of constructor and method objects instantiated by the 
beans 210 within bean-based application 216 to call the 
appropriate constructors and methods for the target class in 
the implementation code 202 as will be hereinafter 
explained in detail. The bean compiler 208, the bean visual 
environment add-on 212 and the universal transport API 
206, function together to allow Java objects and components 
to be manipulated by means of a standard visual builder 214 
regardless of whether the objects were originally designed to 
be used as beans. Bean components, which are normally not 
compatible with visual builder 214, can be incorporated 
therein by means of the inventive bean creator 200. 

The bean compiler 208 generates code for the constructor 
beans and method beans by subclassing and modifying two 
main classes, which are illustrated in FIG. 4. These classes 
include the ConstructorSmartBean class 402 and the Meth- 
odSmartBean class 406, each of which has a set of properties 
and methods. For example, the ConstructorSmartBean class 
402 has properties 404, which include the properties fTypes 
and fParams, which, as will hereinafter be described in more 
detail, are used to specify the type of constructor which will 
be used to instantiate an object from the target class. The 
ConstructorSmartBean properties also include the fTrans- 
port reference and the fPropertyChange reference, which are 
used to reference a transport object which will be used to 
forward the constructor and method calls to the target class 
and to reference a notification object that is part of a 
conventional notification system. 

The ConstructorSmartBean class 402 also includes the 
plurality of methods including the targetClassConstructor( ) 
method, which is used to invoke the constructor of the target 
class, the getConstructorParameter( ) method, which is used 
to obtain parameters required by the 
targetClassConstructor( ) method and the 
refreshProperties( ) method, which is used to broadcast data 
change notifications. 

Similarly, the MethodSmartBean class 408 includes prop- 
erties 410, including the properties fTypes, fParams, 
fTransport, and fPropertyChange which are analogous to the 
similarly-named properties in the ConstructorSmartBean 
class 402. In addition, the MethodSmartBean class 408 
includes an additional property, fResult, which is used to 
hold a result returned by the associated method call. 

The result property can be manipulated by the 
putMethodResult( ), and getResult( ) methods, which are 
used to invoke force the result to a specified value and read 
the result. The MethodSmartBean class 408 also includes the 
targetClassConstructor( ), getTypes( ) and getParameters( ) 
methods, which are used in invoking a constructor in the 
target class and an additional method, callMethod( ), which 
is used to invoke the associated method. 

Three additional classes, the SmartConstructor class 414, 
the MethodEvent class 416, and the ExceptionEvent class 
418 are instantiated by the constructor and method beans to 
encapsulate various parameters and data which are associ- 
ated with the constructor and methods of the target class and 
exceptions generated by the constructor and methods. 
Objects instantiated from these latter classes, are then 
forwarded, via the transport mechanism discussed 
previously, to the target class. In particular, the SmartCon- 
structor class 414 encapsulates the parameters used in the 
constructor which instantiates the target class. Similarly, 
parameters associated with a method are encapsulated in the 
MethodEvent class 416 for transmission to the target object. 
Finally, exceptions generated by the target object are encap- 
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sulated in the ExceptionEvent class 418 for transmission duces the JAR and manifest files which contain the newly- 
back to the constructor or method bean, which initiated the produced beans. The beans are loaded into the JAR file in 
constructor or method call. step 810. 

A routine for generating and compiling code for a con- In step 812, the new beans are placed on the palette of a 
structor bean is illustrated in FIG. 5. The routine starts in 5 visual builder using the visual environment add-on. In step 
step 500 and proceeds to step 502 where the Java class code 814, the bean visual environment add-on is used, in con- 
is parsed. In step 504, the parsed code is examined to extract junction with a visual builder 1320, to create a bean-based 
methods, fields, parameters, and comments. application. At step 816, the process is complete. 

Next, in step 506, the code for the constructor bean is Once a bean-based application is created, it interacts with 

generated by subclassing the ConstructorSmartBean class 10 the code implementing the underlying Java class by means 

402, and, in step 508, customizing the resulting subclass. of a universal transport API. This process is illustrated in 

During this process the parameters of the original construe- FIG. 2 where bean-based application 216 uses universal 

tor become the bound properties of the constructor bean with transport API 206 to operate with class implementations 

the suffix "_CP" added. In this context a "bound" property 202. FIG. 9 illustrates the contents of the universal transport 

is a property which generates a data change notification is API 206, which include several Java interfaces 902 and 906 

when its value is changed. and implementation classes 910 and 912. The universal 

In step 510, the bean code is compiled into the constructor transport API 900 provides a framework for manipulating 

bean which is given a name derived from the original Java Java objects in a "bean-oriented" manner according to the 

class. The routine then finishes in step 512. ITransport interface 902. Interface 902 contains methods 

A similar routine is used to create and compile code for 20 904 which allow either local or remote objects to be con- 

the method beans. Such a routine is shown in FIG. 6, which structed using both null and complex constructors 

starts in step 600 and proceeds to step 602, in which the (fireConstructor), methods to be called (fireMethod), and 

method code is parsed. In step 604, the parameters and field values to be set and retrieved (setField and getField, 

comments associated with the method are extracted. respectively.) A null constructor is one which has no param- 

Next, in step 606, the method bean code is generated by 25 eters whereas a complex constructor is passed parameters or 

subclassing the MethodSmartBean class 408 and customiz- arguments to construct objects. 

ing the subclass as indicated in step 608. During this process The interface 902 has two implementations: LocalTrans- 

the parameters of the original method become the bound port 910 and RemoteTransport 912. The LocalTransport 

properties of the method bean. In addition, the special bound implementation 910 translates application-specific messages 

property called "result" is created to receive the result, if 30 into method calls on local Java objects (not shown.) The 

any, of the method call. Next, in step 610, the bean code is RemoteTransport implementation 912 is utilized in conjunc- 

compiled into the method bean with a name derived from the tion with a distributed object architecture to translate 

original method name. The routine then finishes in step 612. application-specific messages into method calls on remote 

The beans produced by the bean compiler can be used Java objects (not shown.) If distributed object framework is 

with a conventional visual builder by means of an add-on 35 used, remote objects, such as RMI objects, CORBA objects 

application. Referring to FIG. 7 of the illustrative or Java objects which are not RMI or CORBA compliant can 

embodiment, a visual environment add-on (VEA) program be accessed by selecting an appropriate adapter (not shown) 

700 extends the capability of a standard Java "bean- for the object model. 

compliant" visual builder 708 to give the user of the visual The universal transport API 900 also includes an IProp- 

builder 708 access to methods and constructors, as beans, 40 ertyChange interface 906 which contains, among other 

within any OOP code. The Java bean-compliant visual things, a method 908 that transmits data change notifications 

builder 708 can be any conventional visual builder, such as to registered listeners in accordance with a conventional 

the Visual Age WebRunner™ marketed by International notification arrangement. 

Business Machines Corporation, Armonk, N.Y In order to use the universal transport API 900, a transport 

VEA 700 allows access by the visual builder 708 to beans 45 object is first instantiated from the LocalTransport or the 

contained in JAR file 702, which beans may be the beans RemoteTransport class according to the location of the target 

created by the bean creator as discussed above. VEA 700 class implementations. Then, a constructor bean method or 

makes the method and constructor beans available to be read method bean method which invokes a target method in the 

into the "palette" of the visual builder 708. A user can then target class encapsulates the target method parameters in an 

copy beans from the palette into the visual builder "work- 50 object instantiated from the MethodEvent class 416 (FIG. 4) 

space" to customize and combine the beans as needed in in order to permit late binding. The MethodEvent object can 

order to create a new OOP application 710 in a conventional be serialized and transmitted over a network by the 

manner. Non-bean text-based OOP code can also be read in fireMethod method in the transport object to the class 

using the VEA's Interactive Development Environment implementations. Exceptions, and other throwables, are 

(IDE) 712, which, in turn, uses the aforementioned bean 55 encapsulated in an object created from ExceptionEvent class 

compiler to produce beans that are usable by the visual 418 which also allows for serialization. The ExceptionEvent 

builder 708. class 418 allows exceptions which would normally be lost to 

Referring to FIG. 8, the entire process of creating bean- be transmitted back to the client application. For example, a 

based applications from original text-based OOP code is remote RMI -compliant object which stores employee infor- 

illustrated. The process starts in step 800 and proceeds to 60 mation for a business will throw an exception when a look 

step 802 where object-oriented design code is read in to the up error such as "Employee not found in records" occurs. In 

bean creator 200. accordance with normal RMI operation, this exception will 

In step 804, the class code is parsed and the constructors, be hidden from the client by a java.RMI.RemoteException 

methods and other information discussed above is extracted. object and appear to the client as a network failure, rather 

The extracted information is used to generate bean code 65 than the lack of the searched instance. However, with the 

which is then compiled, in step 806, to produce method and inventive bean creator using the API transport 206, encap- 

constructor beans. In step 808, the bean creator 200 pro- sulation and serialization of the exception allows the original 
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exception, "Employee not found in records," to propagate 
from the server back to the client. 

Constructor parameters are encapsulated in a SmartCon- 
structor class 414, which also permits Late binding and 
serialization. Methods which set and get field values in the 
target object are also serialized, but they are not encapsu- 
lated within separate classes because this encapsulation is 
handled by the Smart Constructor class 414. Therefore, the 
RemoteTransport implementation 912 allows direct access 
to remote native methods in a Java class without requiring 
a server-side wrapper class to be used. Generation of such a 
server-side wrapper class would require manual coding go 
and could perturb the original code design, both of which are 
undesirable. 

FIG. 10 illustrates, in a schematic fashion, the operation 
of the constructor and method beans in conjunction with a 
transport object to manipulate the code for the target object. 
A single constructor bean and a single method bean are 
shown, but additional beans can be generated which operate 
in the same manner as those shown. Constructor bean 1000 
includes a targetClassConstructor( ) method 1002 which is 
designed to invoke either a null, or a complex, constructor 
in the target class. The setField( ) and getField( ) methods 
1004, 1006, respectively, are used to manipulate values in 
fields and properties of the target object. In addition, con- 
structor bean 1000 includes two methods designated as 
Method 1 1008 and Method 2 1010. These methods interact 
With methods in the transport object 1046 to invoke meth- 
ods in the Java class implementation 1048. For example, 
when the targetClassConstructor( ) method 1002 is invoked 
in constructor bean 1000, it instantiates a Smart Constructor 
object 1018 passing in any parameters which are required 
for invocation of the constructor in the target class. The 
SmartConstructor object 1018 is, in turn, passed to the 
fireConstructor( ) method 1030 in the transport object 1046. 
The fireConstructor( ) method 1030, in turn, invokes the 
constructor 1050 with the appropriate parameters in the 
target class implementation 1048 to construct the target 
object. 

Fields in the target object, such as field 1052 can be 
manipulated by means of the setField( ) method 1004 in 
constructor bean 1000. The setField method, in turn, invokes 
the setField method 1032 in the transport object 1046 in 
order to insert a value into field 1052 of the target object. 
Similarly, the value in field 1052 can be retrieved by means 
of the getField( ) method 1034 in transport object 1046 and 
returned to the getField( ) method 1006 in constructor bean 
1000. 

If Method 1 (1008) is invoked in constructor bean 1000, 
it instantiates a MethodEvent object 1020 which encapsu- 
lates parameters and data associated with the method. The 
MethodEvent object 1020 is then passed to the fireMethod( ) 
method 1036 in transport object 1046. The fireMethod( ) 
method invokes Method 1 (1054) in the target object passing 
in the encapsulated parameters as necessary. An invocation 
of Method 2 (1010) instantiates a second MethodEvent 
object 1022 which is then passed to the fireMethod( ) 
method 1036 to invoke Method 2 (1056) in the manner 
previously described. 

If either of the methods 1054 or 1056 generates an 
exception or other throwable, the throwable is returned via 
the return Throwable( ) method 1038 in transport object 
1046 which, in turn, creates an ExceptionEvent object 1024 
encapsulating the exception parameters including any 
exception text. The ExceptionEvent object is then returned 
to the constructor bean 1000. 

The method bean 1012 operates in a similar manner. It 
also contains a targetClassConstmctor( ) method 1014 
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which, in turn, instantiates a SmartConstructor object 1026 
that can be applied to the fireConstructor( ) method 1040 in 
transport object 1046. Method 1040 may be the same as 
method 1030, but is shown separately for clarity. This 
s operation constructs the target object if it is not already 
constructed. 

Similarly, an invocation of the callMethod( ) method 1016 
in method bean 1012 causes a MethodEvent object 1028 to 
be instantiated, which MethodEvent object encapsulates the 
10 parameters of the method. The MethodEvent object 1028 is, 
in turn, passed to a fireMethod( ) method 1042 (which may 
be the same as method 1036) in the transport object 1046 
which, in turn, invokes the proper method in the target 
object. 

15 The result generated by an invoked method is returned by 
the retumResult( ) method 1044 in transport object 1046 
which transports the result to the Result property 1017 in 
method bean 1012. 
The following is an example of the operation of the bean 

20 compiler. In this example the target class is a Java class 
called Accountlnfo. The class contains the account owner's 
first and last names and retrieves information about an 
account owner, including the owner's date of birth (DOB), 
account balance and type, etc. The COM. test .Accountlnfo 

25 class has a class definition as follows: 
package COM.tesl; 
public class Accountlnfo 
{ 

public String firstNamc, lastName; 
30 public AccountInfo(String SSN) 
throws Exception 
{...} 

public String getDOB 
{...} 

35 public String getAccountType( ) 
{•■■} 

public Float getBalance( ) 
{...} 

public void setBalance (Float bal) 

40 { . . . } 

public String createReport (boolean history) 

{...} 

} 

Using the inventive bean compiler, two classes would be 
45 generated based upon this class definition. The first gener- 
ated class is a constructor bean for the class constructor: 
public Accountlnfo (String SSN). 
The skeleton of the constructor bean class would be as 
illustrated in the Java code snippet which follows: 
50 package COM, test; 

public class AccountlnfoSBCl 
extends ConstructorSmartBean 
implements java.io.Serializable 

55 < 

//Constructor Type array 

private Class fTypes [ ]-{String.class}; 

//Constructor Parameters 

private Object fParams [ ]»new Object [1]; 

60 

} 

Note that this constructor bean class inherits from the 
constructor bean base class, ConstructorSmartBean, and is 
serializable. The "SBC1" postfix indicates that this is con- 
65 structor number 1 for a constructor bean., The class also 
contains two private fields. The first field fTypes is used to 
locate the correct constructor for the target object The 
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second field, fParams, is used to hold and pass the construc- 
tor parameters, which appear in this constructor bean as 
properties. 

Next, the constructor for the AccountlnforSBCl construc- 
tor bean class is created as illustrated in the Java code 
snippet below; 

public AccountInfoSBCl( ) throws Exception 
{ 

superf ) 
try 
{ 



setConstructor (new SmartConstructor 
("COM.test.AccountInfo", fTypes)); 

\ 

catch (Exception e) 
{ 
} 



} 

This constructor instantiates a SmartConstructor object 
for the eventual target class COM.test.AccountlDfo. 

Next, code to handle the retrieval of the constructor 
parameters, as well as property change notifications for the 
target object's original fields is generated as shown in the 
following Java code snippet: 
public Object [ ] getConstructorParameters( ) 
{return fParams;} 
public void refreshProperties( ) 
{ 

fPropertyChange. firePropertyChangeC'lastName", null, 

getLastName( )); 
fProperty Change. fircPropertyChange(" firstName", null, 

getFirstName( )); 
fPropertyChange. fireProperlyChaage("DOB", null, 
' getDOB()); 

fPropertyChange. firePropertyChange("accountType", 

null, getAccount Type( )); 
fPropertyChange.firePropertyChange("balance", null, 

getBalance( )); 

Note the reference fPropertyChange to a data notification 
object which transmits the data change to all interested 
"listener" parties. 

Next, code to handle the getting and setting of properties 
originally specified as public fields on the target object is 
created. The following code snippet illustrates the code 
which manipulates the target object lastName field. The 
code for other fields is aoalogous. This code uses a reference 
fTransport to a transport object which conveys the object 
invocations to the target object: 
public String getLastName( ) 

{ 

try 
{ 

return (String) fTransport.getField^lastName"); 

\ 

catch (Throwable t) 
{return null;} 

} 

public void setLastName(String data) 
{ 



try 



} 



Object oldofTransport.getReocntField ("lastName"); 
fTransport.setField('iastName", data); 
fPropertyChange. firePropcrtyChange(" lastName, old, 
data); 
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catch (Throwable t) 
{return;} 

Note that a property change notification is sent when the 
value of the lastName field changes indicating that this is a 
5 bound field. Since certain methods of the target class are 
treated as constructor bean properties because of the set/get 
design patterns they express, they are handled as illustrated 
in the following code snippet. Only the getBalaoce( ) and 
setBalance methods are illustrated, other methods are treated 
1Q in a similar manner, 
public Float getBalance( ) 



{ 



try 
{ 

1S Class types[ ]-{ }; 

Object paramsf ]— { }; 

MethodEvent method=new MethodEvent (this, 

"getBalance", types, params, true); 
return (Float) fTransport. fireMethod( method); 

} 

catch (Throwable t) 
{return null;} 



20 



} 

public void SetBalance (Float data) 
25 { 

try 
< 

Object old«fT^anspo^t.getRecentField("bala^ce , '); 

Class types [ ]={Float.class}; 
30 Object params [ ]={bal}; 

MethodEvent mcthod»new MethodEvent (this, 
"setBalance", types, params, true); 

fTransport.fireMethod(method); 

fPropertyChange.fi^ePrope^tyChange("balance ,, , old, 
35 bal); 

return; 

} 

catch (Throwable t) 
{return;} 

The inventive bean compiler also generates a bean for 
each method in the target class. The bean has the same name 
as the method with a postfix "SBM." The "SBM" postfix 
indicates this is a method bean. A partial class definition for 
the createReport method in the sample target class is illus- 
45 trated by the following Java code snippet: public class 
CreateReportSBM 

extends McthodSmartBean 



{ 



50 



private String fResult=null; 
private Class fTypes[ ]-{Boolean.class}; 
private Object fParams[ ]=new Object [1]; 



} 

As with the aforementioned constructor bean, this class 
55 also contains two private fields. The first field fTypes is used 
to locate the correct constructor for the target object. The 
second field, fParams, is used to hold and pass the construc- 
tor parameters, which appear in this bean as properties. This 
method bean class also has a third private field, namely the 
60 fResult field used to hold the result from the method call. 
The constructor for this method Bean is generated as fol- 
lows: 

public CreateReportSBM( ) 
super ("createReport"); 
65 fParams[0]-Boolean.FALSE; } 

This constructor passes the name of the target object 
method to its parent's constructor. It also initializes the 
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parameters array. Note that since the parameter for the 
method is a primitive type, the compiler must be intelligent 
enough to convert to the corresponding Object type, as well 
as to supply a default value. 

The illustrative method bean also contains the next code 
section which is similar for any method bean: 
public void putMethodResult (Object result) 

< 

£Result=(String) result; 

fPropertyChange.firePropertyChange("resuU", null, 
fResult); 
} 

public String getResult( ) 
{ 

return fResult; 

} 

The first method, putMethodResult, allows the parent 
class to set the result value returned from a method call, and 
also allows the method bean to generate a data change 
notification when the result value is changed. The second 
method merely allows the result to be treated as a readable 
property. Note that for each method bean, the result type 
may be different. 

The following two additional methods in the method bean 
code allow the parent class to retrieve the method types and 
method parameters: 
public Class [ ] getTypes( ) 
{ 

return fTypes; 

} 

public Object [ ] getParameters( ) 
{ 

return fParams; 

} 

The following additional methods handle the parameters 
of the target method itself, while treating these parameters as 
bound properties of the method bean, 
public boolean getHistory( ) 
{ 

return 

((Boolean)ff arams[0]).booleanValue( ); 

} 

public void setHistory(boolean data) 
{ 

Object old=fParams [0]; 
fParams [0]=new Boolean (data): 
fPropertyChange.firePropertyChange("History", old, 
fParams[0]); 

} 

' Note again the primitive to corresponding-data-type 
translation. This is needed for fields of types iot, short, long, 
boolean, byte, char, float, and double. 

A software implementation of the above-described 
embodiment may comprise a series of computer instructions 
either fixed on a tangible medium, such as a computer 
readable media, e.g. a diskette, a CD-ROM, a ROM 
memory, or a fixed disk, or transmissible to a computer 
system, via a modem or other interface device over a 
medium. The medium can be either a tangible medium, 
including, but not limited to, optical or analog communica- 
tions lines, or may be implemented with wireless techniques, 
including but not limited to microwave, infrared or other 
transmission techniques. It may also be the Internet. The 
series of computer instructions embodies all or part of the 
functionality previously described herein with respect to the 
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invention. Those skilled in the art will appreciate that such 
computer instructions can be written in a number of pro- 
gramming languages for use with many computer architec- 
tures or operating systems. Further, such instructions may be 

5 stored using any memory technology, present or future, 
including, but not limited to, semiconductor, magnetic, 
optical or other memory devices, or transmitted using any 
communications technology, present or future, including but 
not limited to optical, infrared, microwave, or other trans- 

10 mission technologies. It is contemplated that such a com- 
puter program product may be distributed as a removable 
media with accompanying printed or electronic 
documentation, e.g., shrink wrapped software, pre-loaded 
with a computer system, e.g., on system ROM or fixed disk, 
or distributed from a server or electronic bulletin board over 

15 a network, e.g., the Internet or World Wide Web. 

Although an exemplary embodiment of the invention has 
been disclosed, it will be apparent to those skilled in the art 
that various changes and modifications can be made which 
will achieve some of the advantages of the invention without 

20 departing from the spirit and scope of the invention. For 
example, it will be obvious to those reasonably skilled in the 
art that, although the description was directed to a particular 
language, other object-oriented languages would also be 
suitable for the invention. Similarly, although a particular 

25 hardware system and operating system is described, other 
hardware and operating system software could be used in the 
same manner as that described. Other aspects, such as the 
specific instructions utilized to achieve a particular function, 
as well as other modifications to the inventive concept are 

30 intended to be covered by the appended claims. 
What is claimed is: 

1. Apparatus for allowing text-based object-oriented class 
code to be used with a visual builder that operates with 
software having a predetermined format, the apparatus 

3 5 implemented on a computer system having a memory and 
comprising: 

a parser responsive to text-based object-oriented class 
code that is not in the predetermined format for extract- 
ing selected information from the class code; 

40 a compiler for creating proxy components from the 
selected information, the proxy components represent- 
ing the parsed text-based object-oriented class code in 
the visual builder and containing software code in the 
predetermined format; and 

45 an add-on program which allows the proxy components to 
be used with the visual builder. 

2. The apparatus of claim 1 wherein the selected infor- 
mation includes constructors, methods and parameters. 

3. The apparatus of claim 2 wherein the compiler creates 
50 a proxy component from each constructor and method. 

4. The apparatus of claim 3 wherein the methods include 
parameters and wherein the compiler includes a converter 
which converts the method parameters into proxy compo- 
nent properties. 

55 5. The apparatus of claim 4 wherein the component 
properties are bound. 

6. The apparatus of claim 1 further comprising a transport 
mechanism which is responsive to the proxy components for 
controlling the object-oriented class code. 

60 7. The apparatus of claim 6 wherein each proxy compo- 
nent includes a method with parameters and wherein the 
proxy component is responsive to an invocation of the 
method for instantiating an event object encapsulating the 
method parameters. 

65 8. The apparatus of claim 7 wherein the transport mecha- 
nism is responsive to an event object for controlling the 
object-oriented class code. 
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9. The apparatus of claim 7 wherein exceptions which 
occur during operation of the method are encapsulated in an 
exception event object. 

10. The apparatus of claim 1, wherein a constructor proxy 
component includes a constructor and wherein the construc- 
tor proxy component is responsive to an invocation of the 
constructor for instantiating a target object from the object 
oriented class code. 

U, A method for allowing text-based object-oriented class 
code to be used with a visual builder that operates with 
software having a predetermined format, the method imple- 
mented on a computer system having a memory, and com- 
prising the steps of: 

(a) extracting selected information from text-based 
object-oriented class code that is not in the predeter- 
mined format; 

(b) creating proxy components in the memory from the 
selected information, the proxy components represent- 
ing the parsed text-based object-oriented class code in 
the visual builder and containing software code in the 
predetermined format; and 

(c) connecting an add-on program to the visual builder 
which add-on program allows the proxy components to 
be used with the visual builder. 

12. The method of claim 11 wherein the selected infor- 
mation includes constructors, methods and parameters. 

13. The method of claim 12 wherein step (b) comprises 
the step of: 

(bl) creating a proxy component from each constructor 
and method. 

14. The method of claim 13 wherein the methods include 
parameters and wherein step (b) comprises the step of: 

(b2) converting the method parameters into proxy com- 
ponent properties. 

15. The method of claim 14 wherein step (b) comprises 
the step of: 

(b3) converting the method parameters into bound proxy 
component properties. 

16 . The method of claim 11 further comprising the step of: 

(d) using a transport mechanism which is responsive to 
the proxy components for controlling the object- 
oriented class code. 

17. The method of claim 16 wherein each proxy compo- 
nent includes a method with parameters and wherein step (d) 
comprises the step of: 

(dl) instantiating an event object encapsulating the 
method in response to an invocation of the method. 

18. The method of claim 17 wherein step (d) comprises 
the step of: 

(d2) using the transport mechanism in response to an 
event object for controlling the object-oriented class 
code. 

19. The method of claim 17 further comprising the step of: 

(e) encapsulating exceptions which occur during opera- 
tion of the method in an exception event object. 

20. The method of claim 11, wherein a constructor proxy 
component includes a constructor and wherein step (d) 
further comprises the step of: 

(d3) instantiating a target object from the object oriented 
class code in response to an invocation of the construc- 
tor. 
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21. A computer program product for allowing text-based 
object-oriented class code to be used with a visual builder 
that operates with software having a predetermined format, 
the computer program product comprising a computer 
5 usable medium having computer readable program code 
thereon including: 
program code for extracting selected information from 
text-based objects oriented class code that is not in the 
10 predetermined format; 

program code for creating proxy components from the 
selected information, the proxy components represent- 
ing the parsed text-based object-oriented class code in 
15 the visual builder and containing software code in the 
predetermined format; and 
an add-on program for connection to the visual builder 
which add-on program allows the proxy components to 
be used with the visual builder. 
20 22. The computer program product of claim 21 wherein 
the selected information includes constructors, methods and 
parameters. 

23. The computer program product of claim 22 wherein 
the program code for creating proxy components comprises 

15 program code for creating a proxy component from each 
constructor and method. 

24. The computer program product of claim 23 wherein 
the methods include parameters and wherein the program 

3Q code for creating proxy components comprises program 
code for converting the method parameters into proxy 
component properties. 

25. The computer program product of claim 24 wherein 
the program code for creating proxy components comprises 

35 program code for converting the method parameters into 
bound proxy component properties. 

26. The computer program product of claim 21 further 
comprising: 

program code for creating a transport mechanism which is 
+0 responsive to the proxy components for controlling the 
object-oriented class code. 

27. The computer program product of claim 26 wherein 
each proxy component includes a method with parameters 
and wherein the proxy component includes program code 

45 for instantiating an event object encapsulating the method in 
response to an invocation of the method. 

28. The computer program product of claim 27 wherein 
the program code for creating a transport mechanism com- 

50 prises program code for using the transport mechanism in 
response to an event object for controlling the object- 
oriented class code. 

29. The computer program product of claim 27 further 
comprising program code for encapsulating exceptions 

55 which occur during operation of the method in an exception 
event object. 

30. The computer program product of claim 21, wherein 
a constructor proxy component includes a constructor and 
the constructor proxy component comprises program code 

60 for instantiating a target object from the object oriented class 
code in response to an invocation of the constructor. 

***** 



09/20/2003, EAST Version: 1.04.0000 



